The sharing of storage is an important aspect of many computer systems. Specifically, the ability to selectively control the data areas that are accessible to the units of work within the system is an essential function of an operating system. One operating system that allows a user to share pages of storage between address spaces and/or data spaces of the system is the OS/390 operating system, offered by International Business Machines Corporation. In particular, it is the IARVSERV service of OS/390 that provides this ability. IARVSERV is described in "MVS Programming: Authorized Assembler Services Reference", Volume 2, Document Number GC28-1765-03, which is hereby incorporated herein by reference in its entirety.
As another example, on UNIX systems, the mechanism used to create a shared memory segment is the shmget function in the C programming language. Servers then use the shmat C function to attach the shared memory to each of the clients. OS/390 UNIX System Services exploits the IARVSERV function to provide the shmget and shmat functions to UNIX applications on OS/390.
The sharing of storage comes at a high price, though. This is due to the fact that extra control structures are needed to keep track of the shared storage, which in turn necessitates the need for additional storage. Further, this high price can become exorbitant, especially when attempting to share large amounts of storage.
For example, the overhead associated with using a service, such as IARVSERV, to share a segment (e.g., 1 megabyte; 256 pages) of storage can be calculated as follows: EQU X MB*256 pages/MB*(Y+2) connections*32 bytes/page,
where X is the number of megabytes being shared and Y is the number of address spaces connecting to the shared memory segment. The Y+2 accounts for the system overhead in tracking the shared segments. In a large server environment, it is possible to have X=500 Meg and Y represent 500 clients connecting to the server. In this sort of environment, the formula shows: EQU 500 MB*256 pages/MB*(500+2) connections*32 bytes/page=2 Gig
In other words, it would consume 2 gigabytes of real storage to map this 500 Meg of virtual storage for 500 clients.
In addition to the above storage, there is also a need to account for the pages used for the page tables associated with the storage to be shared. Each page table consumes 4 k of real storage (assuming all clients are paged in) for each megabyte of shared memory. Thus, the overhead for the page table is: EQU X MB*4 Kbytes/MB*(Y+1) connections.
Plugging in 500 Meg for X and 500 for Y for the above example, shows that the page tables will consume an additional 1 gigabyte of real storage. Thus, three additional gigabytes of real storage would be needed in the above example. This need for such an exorbitant amount of additional storage has previously made the sharing of large amounts of storage unrealistic.
Based on the foregoing, a need exists for the ability to share large amounts of storage, without the overhead of additional control structures. Further, a need exists for the ability to share large amounts of storage without incurring exorbitant costs in terms of real storage. Yet further, a need exists for a capability that allows a client address space to attach to the same shared memory multiple times at different virtual addresses without incurring additional overhead.